Distributed computing systems spend a significant amount of time communicating data between various system entities, which may or may not be physically co-located. Traditionally, two different approaches have been utilized in exchanging information between system elements: point-to-point topologies and mediator topologies. FIG. 1A shows an example of a point-to-point network topology 100. Each of the entities 101 has a direct communication link with every other entity. A central directory server 102 is used to locate the desired end points prior to connection establishment. In many cases, physical point-to-point communication is not possible due to the number of elements in the network or due to interconnecting disparate network topologies that prevent point-to-point communication.
FIG. 1B shows an example of a mediator, or proxy, network topology 105, which is used where the various network elements 106 do not have direct physical access to each other. Instead all messaging flows, including directory activity, through server 107 with the assistance of central directory server 108.
Both of these types of network topologies require that the messaging that carries data be customized for the particular applications that process the data. This results in a very rigid system that does not allow the introduction of new elements or applications without potentially extensive re-engineering. Further, both systems require one or more central directory servers that are required to register the location and services of each network element. Other network elements must query the directory to find the desired element or service. If the directory servers are not available, the network becomes non-functional.
For geographically distributed systems, the intercommunication problems can be amplified. For example, for monitoring equipment in a communications network, some elements can be as close as physically on separate blades, but within the same network monitor, or probe. There can also be other elements of the systems that may be somewhere on a third party network, and could even be on the other side of the world. Each of these elements needs to intercommunicate with other network elements. Today's solutions, as illustrated in FIGS. 1A and 1B, are really just a mix match of industry standard network protocols with proprietary messaging on top of the protocol.
However, different sections of the network, or different elements within the network are likely to use different protocols and require a different set of messages. These realities make it very hard to extend current messaging systems to add new capability or to add new elements in the system that need to also receive those kinds of messages. As a result, most networks end up with hard coded messaging protocols between the applications designed to fit specific network implementations and equipment.